As a result of the widespread use and development of electronic commerce (e-commerce, whereby transactions for a variety of goods and services are conducted electronically) and electronic business (e-business, whereby business processes—e.g., shipping, procurement, staffing, etc.—are transformed so as to be conducted electronically), business and enterprise applications have been, and continue to be, developed to interact with numerous back end systems to access and store information related to an e-business or e-commerce transaction. Back end systems (sometimes referred to as Enterprise Information Systems—EISs) include systems related to: parts procurement, receiving, manufacturing or Enterprise Resource Planning (ERP) systems, shipping, accounting and many others.
One commonly used approached to developing business and enterprise applications, particularly those involving a multitiered architecture, is to develop in accordance with the Java™ 2 Platform, Enterprise Edition (J2EE) standard of Sun Microsystems, Inc. Java and all Java—based trademarks are trademarks or registered trademarks of Sun Microsystems, Inc. Multitiered architectures divide an enterprise application into a plurality of computing environments or tiers, typically involving at least three computer platforms in a client/server paradigm. In addition to a client-side platform hosting a client application, the server-side of the architecture environment often involves a server-side presentation platform, such as a web server, a server-side business logic platform, such as an application server and, for those enterprise applications requiring EIS services, a back end connected EIS platform.
J2EE is intended to simplify enterprise applications and their development by basing the applications on standardized, modular components. J2EE further provides a complete set of services to those components, and handles automatically many details of application behavior to avoid complex programming. J2EE extends many features of the Java 2 Platform, Standard Edition for Java based applications. J2EE adds full support for Enterprise Java Beans (EJBs) components to capture business logic and Java Servlets API and Java Server Pages (JSPs) for presentation and communication between the server-side and client-side. Support for Extensible Markup Language (XML) technology is also provided in the J2EE standard.
Multitier applications that require the integration of a variety of resources including legacy data and code as well as programmer skill-sets are difficult to design. It is reported that integrating these resources can take up to 50% of application development time. The J2EE standard wraps and embraces existing resources required by multitier applications with a unified, component-based application model and enables co-operating components, tools, systems, and applications for solving the strategic requirements of an enterprise.
The integration of EIS services to a Java-based model for business applications is the subject of much research and development. Many EISs were often not created to interact easily with other systems (i.e., these legacy EISs were often stand alone systems). EISs are typically not developed in accordance with Java standards. The software for such EISs is typically written in other native programming languages, such as Common Business Oriented Language (COBOL), having their own respective native data types. Thus during development and operation of an integrated application, there is a need for a manner of mapping Java types to native types.
To address the complexity in developing a business application incorporating an EIS, resource adapters have been developed which ease the difficulty. The resource adapter (also sometimes referred to as a “connector”) acts as an intermediary or broker between an EIS and a business application requiring the services of the EIS. A resource adapter architecture generally defines a set of services available from an EIS to allow developers to quickly connect and integrate their business applications. Resource adapters typically are supplied by the developer of the EIS. A resource adapter (or connector) appears as a component (or library) specific to an EIS that provides connectivity to the EIS. It is possible to conceptualize the resource adapter's function as analogous to a Java™ Database Connector (JDBC) driver—a programming interface that lets Java applications access data in a relational database.
Without the use of resource adapters, business application developers often do not fully appreciate the complexities involved in leveraging established enterprise applications and end up spending too much time understanding and coding directly to each particular EIS's integration APIs (if APIs are even available). As note, one particular area requiring understanding and programming involves mapping or converting between data types used by the EIS and the data types available to the business application. The hand-coded logic developed for this and other areas often provides narrow opportunities for reuse, because it is application-specific by design.
However, resource adapters are not without their own problems. Firstly, each resource adapter is typically specific to a single EIS. As such, for “n” number of EISs, “n” resource adapters need to be created. This is often not too problematic in isolation. However, the ETS-specific nature of a resource adapter is coupled with the fact that the resource adapters, which are used at runtime (i.e., during execution of a business application), require adapter tools to be created (typically by the manufacturer or provider of the resource adapter) that are used by an Integrated Development Environment (IDE) to create a business application that can utilize the corresponding resource adapter. As such, a resource adapter is not only specific to the EIS with which it is designed to interact, but the tooling which corresponds to the resource adapter is also specific to an IDE. As a result, if tooling is to be created for “m” number of IDEs, “m” adapter tools will also need to be created. Therefore, for a provider of resource adapter—tool sets to provide resource adapter—tool sets for “n” number of EISs and “m” number of IDEs will require the creation of “m”×“n” resource adapter-tool sets to be created. This is an extremely time consuming and costly undertaking. As such, developers of business applications are typically limited to using an adapter-tool set from the EIS supplier and, possibly, using an IDE that the developer typically does not use as their normal or preferred IDE is not supported by the adapter-tool set.
As such, a solution which addresses some or all of these shortcomings is desired.